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REMARKS 

This submission is responsive to the Final Office Action dated July 14, 2006. Applicant 
has not amended the claims. Claims 1-8, 10-18 and 20-25 remain pending. 

Claim Rejection Under 35 U.S.C S 103 

In the Final Office Action, the Examiner rejected claims 1-8, 10-18 and 20-25 under 
35 U.S.C. § 103(a) as being unpatentable over USPN 6,996,63 1 to Aiken Jr. et al. (Aiken) in 
view of USFN 6,128,657 to Okanoya et al, (Okanoya). Applicant respectfully traverses the 
rejection. The applied references fail to disclose or suggest the inventions defined by Applicant's 
claims, and provide no teaching that would have suggested the desirability of modification to 
arrive at the claimed invention. 

Prior to addressing deficiencies of Aiken and Okanoya with respect to the requirements of 
Applicant's claims on a claim-by-claim basis, Applicant generally addresses one obvious 
deficiency relevant to some of the claims, and some deficiencies relevant to all of the claims. 

First, independent claims 1,18 and 22 require that an intermediate computer networking 
device between a plurality of clients and single physical server comprises a plurality of agents 3 
each of the agents assigned to a different one o f a plurality of client TCP connections with the 
intermediate device. As acknowledged by the Examiner, Aiken does not disclose or suggest this 
requirement of independent claims 1,18 and 22, The Examiner relies on Okanoya as teaching 
this requirement. 

However, contrary to this requirement, Okanoya teaches a plurality of state management 
means 2b, 3b and 4b, each of the agents located within one of a plurality of servers 2, 3 and 4, 
rather than within the intermediate central station, to send the status of the servers to a central 
station that performs load balancing amongst the servers. 1 Thus, Okanoya fails to even suggest 
agents within an intermediate device. 

Further, Okanova does not even suggest agent means that are each associated with a 
different one of a plurality of client TCP connections . In fact, there is no discussion of state 
management means 2b, 3b, and 4b in Okanoya with reference to TCP connections, much less 
that each of state management means 2b, 3b and 4b in any way correspond to respective client 

1 Okanoya, FIG. 1, col. S, 11. 15-35. 
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TCP connections. Thus, even when combined, Aiken and Okanoya still clearly fail to teach or 
suggest this requirement of independent claims 1,18 and 22. 

Moreover, Applicant's invention differs from the systems of Aiken and Okanoya in 
fundamental ways, addresses completely different problems, and provides a completely different 
solution. Prior efforts at reducing the burden associated with handling client requests on any 
given server have focused on distributing the requests amongst a plurality of server devices, e.g., 
a server farm. Like many of the references cited in the prior Office Action's, Okanoya is an 
example of such a solution. Okanoya employs a communication controller to distribute traffic 
among a plurality of separate physical servers. 2 Specifically, Okanoya describes a load sharing 
system that operates at the third layer of the OSI network model, j«e., the Network layer, to 
distribute of client requests. See, e.g., Okanoya at col- 12 5 11. 25-30 describing the use of network 
layer functions of the OSI model to distribute requests to clients. 

Although different from Okanoya in some respects, Aiken is also an example of this type 
of solution, i.e., a solution that operates at the network layer to distribute packet streams. Aiken 
discloses a Sysplex 10 that includes a plurality of data processing systems 20, 24, 28, 32 and 36? 
Although the plurality of data processing systems of the Sysplex may be embodied in a single 
device, each of the data processing systems includes a single, respective TCP/IP stack 22, 26, 30, 
34 and 38. 4 Aiken teaches that one of the stacks may act as a "routing" stack to distribute client 
traffic among the other stacks. 5 Aiken makes clear that routing table entry is created for each 
stack. 6 Thus, Aiken is ao example of load balancing at the third layer of the OSI network model, 
i.e., the Network layer, which is responsible for performing routing functions. 7 These typical 
prior art solutions rely on routing functions so as to distribute traffic across physical servers. 

In contrast, Applicant's claims require an intermediate computer networking device that 
has a plurality of server TCP connections to a plurality of respective sockets on a single physical 
server separate from the intermediate device. Claim 17 specifically requires determining an 

2 Okanoya, Abstract. 

J Aiken, Fig. 4, col. 8, 11. 49-52. 

* Aiken, Fig. 4, col. 8, H. 52-55 and 62-65. 

3 Aiken, col. 9, In. 58 - col 10, In. 15. 
6 Id at Abstract 

'ge^ e g ( http://cn.wikipedia.org/wiki/QSI mode] (stating the well-known principle that the Network layer performs 
network routing functions). 
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optimal server socket. Other independent claims require that the intermediate device monitors 
response parameters specific to individual ones of the plurality of server TCP connections (i.e., 
sockets') to the same server, and selects one of the server TCP connections for transmission of 
client requests to the single server using the respective socket based on the monitoring. 

Thus, the literal language of the claims make clear that embodiments of the invention are 
directed to an intermediate device that multiplexes HTTP communications at the across sockets 
. to the same server. Applicants emphasize that this is much more than a subtle difference from 
the prior art approaches cited by the Examiner. For example, it is well known that sockets 
provide an interface between software applications executing at the application layer of the OSI 
network stack (i.e,, layer 5 and above) and the transport layer (i.e., layer 4). 8 Thus, in terms of 
the OSI network stack, sockets are upper-level communication mechanisms that are employed by 
software applications. A single application executing on a client device may, for example, use 
multiple sockets to communicate data to lower layers of the network stack for transport through a 
network. 

Applicant's independent claims require an intermediate device that multiplexes HTTP 
communications across sockets to the same server based on monitoring of respective TCP 
connection. Thus, embodiments according to the claims facilitate selective distribution of client 
requests at a higher level of the network stack than contemplated by Aiken and Okanoya, i.e., at 
the transport layer / application layer of the OSI model by multiplexing connections/sockets 
rather than the layer three network level Neither Aiken nor Okanoya remotely suggests selective 
distribution of traffic among a plurality of connections/sockets to a single physical server based 
on monitoring of the plurality of connections/sockets. Instead, Aiken and Okanoya both teach 
distribution of client requests to different devices or stacks, i.e., at the network layer, by use of 
routing functions. As a result, Aiken in view of Okanoya is unable to address the problems 
addressed by Applicant's claimed intermediate device, Applicants, for example, recognize that 
although the sockets provide access to the same server, different sockets may provide different 
performance based on the state of the upper-layers of the network stacks on the server. 
Consequently, Applicant's claimed intermediate device detects and monitors network connects at 

8 See, e.g., httn://en.-wikipedla,orgAviki/OSI model (providing well-knovm examples that Microsoft Windows's 
Winsock, and Unix's Berkeley sockets and System V Transport Layer Interface, are interfaces between applications 
(layers 5 and above) and the transport (layer 4). 
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the higher layers of the network stack, i.e., sockets, and multiplexes across different sockets even 
though those sockets provide communications to the same server. The routing and load- 
balancing operations taught by Aiken in view of Okanoya do not suggest monitoring or 
multiplexing at these layers of the network stack, do not address any of the problems addressed 
by Applicant's solution and fail to suggest any of solution to these problems. For example, even a 
system that load-balances across different devices, such as the Aiken system and the Okanoya 
system, may still experience drastically different performance variations between sockets of the 
same device. The systems described by Okanoya and Aiken do not even recognize these issues 
nor do the systems provide any mechanism for addressing these issues. 

Moreover, Aiken describes systems fundamentally different from what is required by 
Applicant's independent claims. As stated above, Applicant's claims require an intermediate 
computer networking device and a single, separate physical server, as well as a plurality of server 
TCP connections between the intermediate device and the server. Further, as discussed above, 
Applicant's claims require monitoring of the TCP connections between the intermediate device 
and the server device, and selective distribution of client requests on the TCP connections 
between the intermediate device and the server device based on the monitoring, Aiken does not 
teach or suggest such a system. 

Instead, Aiken teaches that the routing systems 20, 36 and the "target" systems 24, 28, 32 
(to which requests are routed) in the Sysplex 10 may be embodied in a single device . 9 Thus, in 
such embodiments, there is no intermediate routing device and separate physical server device, as 
required by Applicant's claims. 

Aiken also suggests that, in alternative embodiments, each of the routing and target 
systems may be embodied as a separate device. 10 However, Aiken does not even suggest that a 
plurality of TCP connections between a single one of the routing system and a single one of the 
target systems are monitored or that client requests are selectively distributed over sockets 
corresponding to those connections based on the monitoring. Thus, this embodiment of Ai ken 
also fails to meet the requirements in Applicant's claims of two separate devices coupled by 
plurality of TCP connections, monitoring of the plurality of TCP connections between the two 



9 Aiken, Fig. 4, col. 8, 11.52-55. 

10 Aiken, Fig. 4, col. 8, 11. 55-60. 



PAGE 7/14 * RCVD AT 1 0/1 6/2008 4:30:49 PM [Eastern Daylight Time] 1 SVR:llSPTO-EFXRF-2/15 * DNIS:2738300 1 CSID:6517351 102 1 DURATION (mnws):04-36 



10/16/2096 15:28 6517351102 



SHUMAKER & SIEFFERT 



PAGE 08/14 



Application Number 09/975,522 

Responsive to Office Action mailed July 14, 2006 

devices, and selective distribution of client requests over the plurality of TCP connections 
between the two devices. 

Claims 1 and 2 

Aiken and Okanoya fail to disclose or suggest a number of the requirements of 
independent claim 1 . For example, Aiken and Okanoya fail to disclose or suggest a computer 
networking device comprising an HTTP multiplexor/demultiplexor that monitors response 
parameters specific to indi vidual ones of a plurality of server TCP connections from the 
computer networking device to a single physical server device, as required by independent claim 
1. As discussed above, Aiken and Okanoya do not contemplate distribution of client requests at 
the connection/socket level, and thu$ do not disclose or suggest an intermediate device that 
monitors response parameters specific to individual ones of a plurality of server TCP connections 
from the intermediate device to a single physical server device. 

In the Office Action, the Examiner asserted that data processing system 20 and data 
processing system 24 of a Sysplex 10 depicted in FIG. 4 of Aiken are the HTTP 
multiplexor/demultiplexor and single physical server required by claim 1 s respectively. 
However, even Aiken does not disclose or suggest a computer networking device separate from 
the system 24 that comprises the system 20 and has a plurality of TCP connections with system 
24, a$ would be if the Examiner's assertion were applied to the limitations of claim 1 . 

For the "computer networking device" requirement of claim 1, the Examiner cited a 
lengthy and very general discussion at col 7, In. 50 - col. 8, In. 50, which merely suggests that 
the Aiken invention may be embodied in hardware or software. This discussion is unrelated to 
the specific system depicted in FIG- 4, and does not in any way suggest that the system in FIG. 4 
includes a computer networking device with a plurality of TCP connections to data processing 
system 24. Nor could data processing system 20 itself be the computer networking device. 
Aiken does not disclose or suggest a plurality of TCP connections between data processing 
systems 20 and 24. Nothing within Aiken suggests a computer networking device with a 
plurality of TCP connections to data processing system 24. 

Moreover, contrary to the Examiner's position, Aiken does not disclose or suggest that 
data processing system 20 monitors response parameters specific to individual ones of a plurality 
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of server TCP connections. For this requirement of claim 1, the Examiner cited col. 10, 11. 1-5, 

which in relevant part states: 

Because communications to the DVIPA are routed through the routing protocol 
stack, the routing protocol stack may provide work load balancing by distributing 
connections to the other protocol stacks on MVS images executing server 
applications which bind to the DVIPA to balance workload. 

Applicant respectfully submits that load balancing does not necessarily involve monitoring, and 

therefore the mere mention of load balancing does not suggest monitoring response parameters. 

Accordingly, this portion of Aiken does not even disclose monitoring response parameters. 

Moreover, as discussed above. Aiken does not suggest a plurality of server TCP connections to 

system 24, which the Examiner argued is a single physical server. Therefore. Aiken certainly 

does not disclose or suggest that system 20 monitors response parameters specific to individual 

ones of a plurality of server TCP connections to a single physical server, as would be required by_ 

application of the Examiner's reason to die limitations of claim 1 . 

Also, the applied references do not disclose or suggest selecting one of a plurality of 
server TCP connections between the intermediate computer networking device and the single 
physical server ba$ed on the monitoring of the response parameters, as required by claim 1 . The 
portion of Aiken cited by the Examiner (col. 16, 11. 15-30) teaches selection from amongst 
different "target" systems 24, 28 and 32 in the Sysplex 10, not selection from amongst a plurality 
of server TCP connections to single physical server. As discussed above, the Examiner's 
argument was that a single one of the target systems, system 24, is the single physical server 
required by claim L Applying the Examiner's analysis of Aiken to the requirement of selecting 
one of a plurality of server TCP connections between the intermediate computer networking 
device and the single physical server would require selection from amongst a plurality of server 
TCP connections to the single system 24, This is not taught by the portion of Aiken cited by the 
Examiner, or anywhere else in the applied references. 

Again, Aiken only contemplates monitoring and selective distribut ion amongst the 
plurality of target systems 24. 28 and 32 in the Svsnlex 10, not amongst a plurality of server TCP 
connections to a single physical server, which is the single system 24 according to the 
Examiner's analysis. 
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Additionally, as discussed above, the applied references do not disclose or suggest an 
intermediate device that includes a plurality of agents, each agent assigned to a different one of a 
plurality of client TCP connections, as required by independent claim 1 . 

Also, with respect to claim 2, the applied references fail to disclose or suggest receiving 
multiplexed HTTP responses from the single physical server over the individual TCP connection 
and routing those responses to the clients via the plurality of client TCP connections. The 
Examiner cited FIG. 12 of Aiken as teaching this requirement of claim 2 without any explanation 
of its relevance. This portion of Aiken is related to changing ownership of virtual. IP address 
amongst communication protocol stacks, and appears to have nothing whatsoever to do with 
sending responses to clients. Applicant respectfully requests the Examiner clarify or withdraw 
this rejection in any Advisory or other subsequent action. 

Claims 3-5 

Similar to requirements of independent claim 1 discussed above, independent claim 3 
requires monitoring a plurality of server TCP connections from a computer networking device to 
a single physical server device to determine a response parameter, and selecting one of the server 
TCP connections based on the determined response parameter. For the reasons discussed at 
length above, Aiken and Okanoya fail to disclose or suggest these requirements of independent 
claim 3. 

Further, Applicant notes that, in rejecting claim 3 ? the Examiner appeared to have 
erroneously identified the client 46 and routing system 20 as being the intermediate computing 
device and single physical server required by claim 3, respectively. Applicant respectfully 
suggests that this may have been the result of a mistake in transcribing the rejection set forth with 
respect to claim 1 in order to reject claim 3. To the extent this was not a mistake, Applicant 
notes that Aiken does not remotely suggest a plurality of TCP connections between the client 46 
and the routing system 20, much less monitoring or selective distribution over a plurality of TCP 
connections between the client 46 and the touting system 20. Again, Aiken only teaches 
monitoring and distribution amongst the plurality of target systems 24, 28 and 32. 

Also, the Examiner's rejection of claim 3 includes a discussion with respect to an HTTP 
multiplexor/demultiplexor that includes a plurality of agents. Applicant respectfully points out 
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that claim 3 does not include these limitations. This mistake also appears to be the result of 
transcribing the rejection of independent claim I in order to reject independent claim 3. 

Claims 6-8 and 10-16 

Similar to requirements of independent claim 1 discussed above, independent claim 6 
requires monitoring a plurality of server TCP connections from a computer networking device to 
a single physical server device at the computer networking device to determine response 
parameters, and selecting one of the server TCP connections based on the determined response 
parameter. For the reasons discussed at length above, Aiken and Okanoya fail to disclose or 
suggest these requirements of independent claim 6. 

Further, with respect to claim 8, the applied references fail to disclose or suggest 
persistent client TCP connections from clients to an intermediate computing device or persistent 
server TCP connections from the intermediate device to the separate physical server device. The 
Examiner cited FIG. 8 of Aiken as teaching this requirement of claim 8 without any explanation 
of the relevance of FIG* 8 to the requirements of the claim. This portion of Aiken is related to 
opening and terminating connections between a routing system and target systems in a Sysplex, 
and thus appears to be directly contrary to the requirements of Applicant's claims. Applicant 
respectfully requests the Examiner clarify or withdraw this rejection in any Advisory or other 
subsequent action. 

Additionally, similar to claim 2 discussed above, claims 14-16 respectively recite 
receiving HTTP responses from a selected server socket, demultiplexing the responses to permit 
selective routing and transmission to corresponding originating clients, and sending the 
responses. Again, the applied references fail to disclose or suggest these limitations, and the 
figure of Aiken cited by the Examiner as teaching these limitations appears to be totally 
irrelevant to these limitations. Applicant respectfully requests the Examiner clarify or withdraw 
these rejections in any Advisory or other subsequent action. 

Claim 17 

Similar to requirements of independent claim 1 discussed above, independent claim 17 
requires monitoring a plurality of server TCP connections from a computer networking device to 
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a single physical server device at the computer networking device to determine a response 
parameter, determining an optimal server socket based on the determined response parameter, 
and sending received requests as a multiplexed transmission to the optimal server socket via one 
of the plurality of server TCP connections. Similar to claim 2, independent claim 1 7 also 
requires receiving HTTP responses from the single physical server device, demultiplexing the 
responses to permit selective routing and transmission to corresponding originating clients, and 
sending the responses. For the reasons discussed above with respect to claims 1 and 2, the 
applied references fail to disclose or suggest these requirements of independent claim 17. Again, 
Applicant respectfully requests the Examiner clarify or withdraw these rejections in any Advisory 
or other subsequent action. 

Claims J 8> 20 and 2 1 

Similar to requirements of independent claim 1 discussed above, independent claim 18 
requires an intermediate device comprising an HTTP multiplexor/demultiplexer configured to 
monitor response parameters that are specific to individual ones of a plurality of server TCP 
connections from the intermediate device to the physical server device , wherein the HTTP 
multiplexor/demultiplexer of the intermediate device includes a plurality of agents, each agent 
assigned to a different one of the client TCP connections, and wherein one of the agents selects 
one of the plurality of server TCP connections from the intermediate device to the physical server 
device based on the monitoring. For the reasons discussed above with respect to claim 1 , the 
applied references fail to disclose or suggest these requirements of independent claim 18. 

Further, claim 20 requires that the server TCP connections are persistent. As discussed 
above with respect to claim 8, the applied references fail to disclose or suggest this requirement, 
and the teachings of FIG. 8 of Aiken, cited by the Examiner as teaching this requirement, appear 
to in fact be directly contrary to the requirements of Applicant's claims. Again, Applicant 
respectfully requests the Examiner clarify or withdraw this rejection in any Advisory or other 
subsequent action. 
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Claims 22 and 23 

Similar to requirements of independent claim 1 discussed above, independent claim 22 
requires an intermediate device configured to monitor response parameters that are specific to 
individual ones of a plurality of server TCP connections from the intermediate device to the 
physical server device , wherein the intermediate networking device includes a plurality of agents, 
each agent assigned to a different one of the client TCP connections, and wherein one of the 
agents selects one of the plurality of server TCP connections from the intermediate device to the 
physical server device based on the monitoring. For the reasons discussed above with respect to 
claim 1* the applied references fail to disclose or suggest these requirements of independent 
claim 22. 

Further, similar to claim 2 discussed above, claim 23 requires receiving HTTP responses 
from the single server device via a multiplexed transmission, demultiplexing the responses, and 
routing the responses to corresponding clients. Again, the applied references fail to disclose or 
suggest these limitations, and the figure of Aiken cited by the Examiner as teaching these 
limitations appears to be totally irrelevant to these limitations. Applicant respectfully requests 
the Examiner clarify or withdraw these rejections in any Advisory or other subsequent action. 

Claims 24 and 25 

Similar to independent claim 1, independent claim 24 requires a computer networking 
device being configured to monitor a plurality of persistent server socket connections from the 
computer networking device to a single physical server device to determine a response parameter 
that is specific to each of the server socket connections, determine an optimal one of the 
server sockets for each HTTP request based on the respective response parameters for each of 
the server sockets, and to send each HTTP request to the determined optimal server socket for the 
request via a multiplexed TCP transmission. For the reasons discussed above with respect to 
claim 1, the applied references fail to disclose or suggest these requirements of independent 
claim 24. 

For at least these reasons, Aiken in view of Okanoya fails to establish a prima facie case 
for non-patentability of Applicant's claims 1-8, 10-18 and 20-25 under 35 U.S.C. § 103(a). 
Withdrawal of this rejection is requested. 
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CONCLUSION 

All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-$igned attorney to discuss this application. 



Date: 



October 16, 2006 



SHUMAKER & SIEFFERT, P. A. 
8425 Seasons Parkway, Suite 105 
St. Paul, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 




N^tie: Jason D. Kelly* 
No.: 54,213 
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